Re: /etc/utmp
Pat Myrto (ole!rwing!pat@nwnexus.wa.com)
Fri, 25 Mar 94 14:18:08 PST
"In the previous message, ole!merle.acns.nwu.edu!jlacour said..."
>
> > Hmm, anyone can explain a bit more the recent CERT advisory on /etc/utmp.
>
> Perhaps you missed the following:
>
[ ... stuff deleted on comsat example using writeable utmp ... ]
Generally, if one has a world-writeable /etc/utmp file, chances are
excellent one has this kind of a problem or hole.
I don't know of a specific patch, for this. But the only REAL fix is
to make the /etc/utmp file so it is not world-writeable. That means,
of course, fixing anything that must update it, other than login or init
to run SUID root without creating a worse hole. Like the problem with
unpatched xterm (one reason utmp is world writeable, so xterm needn't
be SUID root). Presumably in the case of logins, etc, login inserts
the entry before it changes to the users UID/GID, and init removes the
entry when it notices the login shell has died. There are various
dedicated programs for modifying utmp, and of course one can use a binary
editor. There are relatively few good ones out there (that I like),
ones that act just like vi, except the edit screen looks like a hex dump
with an ASCII column at the right, that doesn't force one to do a save
every time one scrools to the next screen. Most expect one to do a
write before viewing another part of the file.
About all one can really do, without more info, or knowing WHY utmp has
to be world-writeable on a given platform, is to turn off the world-write
perms, and keep an eye out for what breaks, and fix them as they are
discovered. Assuming only a trusted person is running the console (as
in a dialup access system), one can make the utmp file group tty or such
(or even a special group created for the purpose), and the trusted user
also in group tty, with utmp mode 664 and that group. This allws a
non-SUID xterm to properly update utmp. One must also be sure that the
lines in /etc/rc* that zeros utmp as the system is coming up do not
change it to world-writeable perms, as well. This is an approach I
am using until I find the time to get xterm patched and rebuilt.
This is a real problem for people who do not have easy access to source
for xterm or other programs that have to be SUID root to properly update
a non-world writeable utmp. Sometimes one has to get alternate sources
and port it to their platform, THEN fix the problem itself in the newly
ported source. One could write a lot of SUID wrappers, I suppose, that
relenquish the SUID privs, fork and run the original program while the
parent sleeps, then when the child finishes, wake up and remove the
entry. Messy to say the least. Either that, or do without the utmp
info, and perhaps some functionallity. I am sure there are other means
to access files one shouldn't besides just using comsat - nobody has
just uncovered or told anyone about them yet. SunOS's answer was to
make utmp world-writeable instead of fixing xterm, as described above,
and perhaps cmdtool, etc. Does anybody know if similar holes exist in
cmdtool, or other commandline windows that xterm has if run SUID root,
so utmp can have the perms set more sanely? If so, it probably would
be a good idea to let people know, so they can address the problem,
even if 'addressing it' means disabling the offending programs.
--
pat@rwing [If all fails, try: rwing!pat@ole.cdac.com] Pat Myrto - Seattle WA
"No one has the right to destroy another person's belief by demanding
empirical evidence." -- Ann Landers, nationally syndicated advice columnist
and Director at Handgun Control Inc.